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(54) Abstract Title 

Method and apparatus for providing a scalable pervasive notification service 

(57) A notification service is provided for communicating messages to one or more intended recipient 
devices associated with users or subscribers of the notification service. The notification service comprises a 
notification server operatively connected to one or more gateways. Each gateway, in turn, is connected, either 
directly or via a switch, to one or more recipient devices associated with a user(s) or subscriber(s) of the 
notification service. The gateway includes a message queue, for storing messages to be delivered, and/or a 
transcoder for transforming the format type of a message, received from the notification server, to a different 
format type adapted for use by the intended recipient devices. 
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METHOD AND APPARATUS FOR PROVIDING A 
SCALABLE PERVASIVE NOTIFICATION SERVICE 

The method and apparatus of the present invention relate generally to 
communication systems, and more particularly relates to the communication 
of messages to one or more devices associated with an intended recipient in 
an environment in which the devices are pervasive. 

Delivering messages to specific devices is well known in the industry 
today. For example, paging systems deliver messages to their subscribers 
and cellular services deliver telephone calls to their customers. Due, at 
least in part, to the proliferation of these and similar devices, 
individual users frequently have multiple devices that can receive 
messages, or even send messages in return. This leads to a different 
problem: when someone wants to send a message to an individual using 
conventional message delivery systems, the sender must know and maintain 
multiple addresses (e.g., telephone numbers, pager numbers, service 
providers, etc.). Also, the sender may not know which device the intended 
recipient is carrying at any particular point in time, a situation that 
generally results in redundant messages being sent to different devices. 
In addition, the sender may not know the capabilities of the intended 
recipient's device (s) and may send a message to a device which is incapable 
of effectively processing it. Furthermore, the sender may not know on 
which device the intended recipient prefers to receive messages during any 
given time. 

Prior art messaging systems have attempted to address some of the 
issues involving present delivery of messages. For example, in U.S. Patent 
Number 5,928,325, Shaughnessy et al. discuss the problem of keeping track 
of devices associated with a particular user and disclose a solution. in 
essence, Shaughnessy et al. provide a method for sending messages to one or 
more user devices presently available to an intended recipient. This 
system keeps track of the devices associated with each subscriber as well 
as which of those devices are currently active. When someone must get a 
message to a subscriber, they send the message to this system and the 
system sends it directly to one or more of the subscriber's devices. 

Similarly, in U.S. Patent Number 5,493,692, Theimer et al. disclose a 
system (that predates the previously described system) for delivering 
messages to a user or a group of users in an environment containing mobile 
and fixed devices. The Theimer et al . system delivers a message based upon 
the context of the intended recipient. The message may be given a level of 
privacy and a priority as well as contextual attributes for its delivery. 



The system delivers the message to the intended recipient when the 
recipient's environment matches the required contextual situation. 

As an example of another prior art messaging system, MessageBlasterSM 
offers a service that allows subscribers to maintain information about 
their contacts and send one or more of those contacts a message. This 
system will contact each of the identified people using one or more methods 
specified by the sender, including telephone, fax, e-mail, pagers, or mail. 
Each subscriber to the MessageBlaster* 4 system must maintain a personal list 
of contacts as well as device information for each device carried by those 
contacts — a tedious, error-prone and continuous process. Further, this 
approach to message delivery does not allow the recipient any control 

(other than those controls provided by the service provider of the device 
chosen by the sender) over how messages are delivered. A more detailed 
description of this service may be found, for example, by accessing the 
MessageBlaster^ web site at URL address http://www.messageblaster.com 

(originally described on February 10, 2000). 

Although all of the systems described above address some aspect of 
the problems previously described, none of these systems, when considered 
either individually or in combination, addresses all the subtleties of the 
complex issues involved. For example, neither system addresses the problem 
of supporting disconnected devices, or the problem of having a disconnected 
device eventually reconnect to the messaging service. Furthermore, neither 
system exploits the functionality offered by two-way communication systems 
(e.g., two-way paging systems, the Palm VII system, SMS, etc.). Such 
communication systems offer the ability for end users to respond to 
messages received. This functionality provides an opportunity for the 
end-user to respond to messages received via a messaging system and to 
potentially influence the ways in which that messaging system handles 
future requests. Although some prior art messaging systems allow users to 
specify limited user preferences, neither of these systems address how to 
support highly variable user preferences, or to allow users to modify their 
preferences dynamically. In addition, although some of these systems may 
exploit information about the current state of the users, their devices 
and/or their environment, they do not maintain and/or exploit information 
about the users' past habits in making message delivery decisions. 

There remains a need, therefore, in the field of electronic message 
delivery, to support devices that disconnect and later reconnect to the 
system, to exploit the features of two-way communication systems, to handle 
highly variable user preferences, and to consider historical activities and 
preferences in making complex message delivery decisions. 



According to one aspect of the present invention, there is provided a 
notification service for communicating messages to one or more intended 
recipient devices associated with at least one user of said notification 
service, said notification service comprising: a notification server, the 
notification server including one or more databases for storing at least 
one of administrative information, user preferences, gateway information, 
directory service information and awareness information; and at least one 
gateway operatively connected to the notification server, the at least one 
gateway including at least one of: a message queue for storing messages to 
be delivered to said one or more recipient devices operatively connected to 
the at least one gateway; and a transcoder for transforming a message, 
received from said notification server, from a first format type to a 
second format type for use by said one or more intended recipient devices 
operatively connected to the gateway. 

According to a second aspect of the present invention, there is 
provided, in a notification service comprising a notification server 
operatively communicating with at least one gateway, a method for 
communicating a message to one or more recipient devices associated with at 
least one user of said notification service, said one or more devices being 
operatively connected to said at least one gateway, said method, performed 
by said notification server, comprising the steps of: identifying, upon 
receiving a message from a sender, an intended recipient of said message 
and determining whether said intended recipient is a user of the 
notification service; retrieving, if said intended recipient is a user of 
said notification service, from a storage medium operatively coupled to the 
notification server, at least one of: information relating to said intended 
recipient; and information relating to said one or more devices associated 
with said intended recipient; determining, on the basis of said information 
retrieved from said storage medium, whether said message is to be 
delivered; identifying one or more devices, and characteristics 
corresponding thereto, associated with said intended recipient; determining 
the availability of said one or more devices, associated with said intended 
recipient, for receiving said message; and transmitting said message to one 
or more gateways associated with at least one available device from said 
one or more devices associated with said intended recipient. 

According to a third aspect of the present invention, there is 
provided, in a notification service comprising a notification server 
operatively communicating with at least one gateway, said at least one 
gateway including a message queue for storing one or more messages, a 
method for communicating a message to one or more recipient devices 
associated with at least one user of said notification service, said one or 
more devices being operatively connected to said at least one gateway, said 
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method, performed by said at least one gateway, comprising the steps of: 
receiving a message from said notification server; storing said message in 
said message queue; retrieving a message to be delivered from said message 
queue; determining whether said message retrieved from said message queue 
has already been delivered to said one or more recipient devices; 
transmitting said message retrieved from said message queue to said one or 
more recipient devices if said message has not already been delivered; 
determining whether said transmitting of said message was successful; and 
removing said message from said message queue if said transmitting step was 
successful . 

According to a fourth aspect of the present invention, there is 
provided, in a notification service comprising a notification server 
operatively communicating with at least one gateway, said at least one 
gateway including a transcoder, a method for communicating a message to one 
or more recipient devices associated with at least one user of said 
notification service, said one or more devices being operatively connected 
to said at least one gateway, said method, performed by said at least one 
gateway, comprising the steps of: receiving a message from said 
notification server; transforming, for each device of said one or more 
recipient devices, said message from a first format type received from said 
notification server to a second format type adapted for use by said 
recipient device; and transmitting said message retrieved from said message 
queue to said one or more recipient devices if said message has not already 
been delivered. 

The present invention revolutionises the communication of messages to 
an intended recipient (s) of the messages by providing a method and 
apparatus for the collection, transformation and delivery of electronic 
messages to one or more devices associated with the intended recipient. In 
a preferred embodiment, the present invention is capable of: supporting 
disconnected devices; supporting multiple similar devices via a gateway or 
device proxy; supporting highly variable user preferences; supporting 
dynamic device configuration; supporting delivery confirmation to be 
returned to the sender; and supporting transcoding in the gateway to 
increase scalability. 

In accordance with one embodiment, a notification service is provided 
for communicating messages to one or more intended recipient devices 
associated with users or subscribers of the notification service. The 
notification service comprises a notification server operatively connected 
to one or more gateways. Each gateway, in turn, is connected, either 
directly or via a switch, to one or more recipient devices associated with 
a user(s) or subscriber (s ) of the notification service. The gateway 



preferably includes a message queue, for storing messages to be delivered, 
and/or a transcoder for transforming the format type of a message, received 
from the notification server, to a different format type adapted for use by 
the intended recipient device (s). By providing a message queue, the 
gateway supports message delivery to disconnected devices that later 
reconnect to the notification service. Moreover, by employing a gateway 
which includes a transcoder, message transformation can be dynamically 
altered to conform to the specific devices corresponding to the gateway, 
thus providing a notification service that is scalable. 

Features and advantages of the present invention will become apparent 
from the following, by way of example, detailed description of the 
preferred embodiments thereof, which is to be read in conjunction with the 
accompanying drawings, wherein like elements are designated by identical 
reference numerals throughout the several views, in which: 

Figure 1 is a component diagram depicting a notification server, 
formed in accordance with one embodiment of the present invention; 

Figure 2 is a component diagram depicting a gateway, formed in 
accordance with one embodiment of the present invention; 

Figures 3A and 3B are a logical flow diagram illustrating a preferred 
process by which the notification server of Figure 1 delivers a message, in 
accordance with the present invention? Figure 4 is a logical flow 

diagram illustrating a preferred process by which a gateway, such as that 
shown in Figure 2, accepts an incoming message for one of its devices, in 
accordance with the present invention; and 

Figures 5A and 5B are a logical flow diagram illustrating a preferred 
process by which a gateway services the messages in its delivery queue, in 
accordance with the present invention. 

In a preferred embodiment, the present invention is directed to a 
method and apparatus for the collection, transformation, and delivery of 
electronic messages. It is to be appreciated that the present invention is 
not limited by the form or type of data transmission or storage system 
described with relation to the specific embodiments and that those skilled 
in the art will understand that the form of the data transmissions (e.g., 
RF, wireless, dedicated communications channel, etc.), as well as the form 
of the storage systems used for storing information (e.g., magnetic disk, 
optical media, etc.), may vary. 



The present invention may be more fully understood with reference to 
Figure 1, which illustrates the components of an overall notification 
server 1000 used in a notification service architecture, in accordance with 
a preferred embodiment. As shown in Figure 1, the notification server 1000 
preferably includes a database containing administrative information 1010. 
This administrative information may include, for example, service 
subscribers. The information maintained in this database might also 
include, but is not limited to, user identifiers, passwords and encryption 
keys. Those skilled in the art will recognise that this administrative 
database 1010 is preferably a logical database and could be realised as one 
or more physical data stores. Those skilled in the art will also recognise 
that the one or more physical data stores that implement the functionality 
of the logical administrative database 1010 may be implemented in any 
number of ways, including a formal database or a flat file. 

Figure 1 further depicts a preferences databases 1020 included in the 
notification server 1000. This preferences database 1020 preferably 
maintains the preferences of the service's subscribers or users. Those 
skilled in the art will appreciate that this database 1020 may be combined 
with the administrative functionality described previously (similar to how 
a UNIX password file maintains each user's preferred shell). The 
preferences database 1020 may be modified by the user or by an application 
program through the use of, for example, a graphical user interface 1025. 
The method of modifying the preferences database 1020 may vary and is not 
limited to graphical user interfaces. Furthermore, it is to be appreciated 
that the present invention supports user preferences that could potentially 
change frequently. Although the preferences database 1020 is depicted as 
being included within the notification server 1000, the present invention 
similarly contemplates that the preferences database 1020 may be external 
to the notification server 1000. 

Figure 1 also depicts a gateway database 1030. The gateway database 
1030 preferably maintains information about the various gateways accessible 
to the notification service for use in delivering electronic messages. 
This information might include, but is not limited to, service identifiers 
{to identify this notification service to the gateway service), passwords 
and encryption keys. It is to be appreciated that this gateway database 
1030 is preferably a logical database, and may be realised as one or more 
physical data stores. Those skilled in the art will also recognise that 
the one or more physical data stores that implement the functionality of 
the logical gateway database 1030 may be implemented in any number of ways, 
including a formal database or a flat file. 
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With continued reference to Figure 1, there is also shown a 
transcoding engine 1040 which is preferably used to transcode the 
electronic message prior to transmission to the gateway. This transcoding 
might include, but is not limited to, removing images, modifying images , 
5 removing attachments, summarising content, removing confidential material, 

summarising information about the message (e.g., name of sender, date sent, 
subject, etc.) and the like. 

Figure 1 further shows zhe notification server connected to two other 
services, namely, a directory service 1050 and an awareness service 1060. 
The directory service 1050 preferably provides information to the 
notification service regarding the devices available to a particular 
subscriber and the characteristics cf those devices. The directory service 
1050 could be provided by an LDA? database or other common directory 
service. The awareness service 1060, such as that described in the 
co-pending IBM patent application filed on January 7, 2000, serial number 
yet unassigned (IBM docket number YO9-2000-0008 ) , entitled "Method and 
Apparatus for Providing an Awareness-Service Architecture," provides 
information regarding the current accessibility of the devices available to 
a particular subscriber. 

Figure 1 further depicts a number of connections to gateway services 
1070, 1080 and 1090. By way of example, gateway 1070 is shown connected to 
a telephone network, gateway 1080 is connected to an e-mail service network 
25 and gateway 1090 is connected to another communication service. Each of 

the gateway services 1070, 1080 and 1090 is preferably a gateway service 
such as that illustrated in more detail in Figure 2. Figure 1 also shows 
each gateway connected to one or more switches, 1100, 1110, 1120 and 1130. 
These switches, 1100, 1110, 1120 and 1130, if employed, preferably provide 
30 network connectivity to particular devices (These switches may correspond 

to the switch elements designated by reference numerals 31 and 41 in U.S. 
Patent Number 5,928,325). It is to be appreciated that the present 
invention contemplates that a device may also be connected directly to a 
gateway, in which case the switch may be eliminated. 

35 

Figure 1 shows end-user devices 1140, 1150, 1160, 1170 and 1180, each 
of which is preferably connected to an appropriate switch, 1100, 1110, 
1120, or 1130. The switches are in a unique position to report information 
regarding the devices they service to other parties, such as to an 
4 0 awareness service 1060 or to a gateway service. Those skilled in the art 

will recognise that additional gateways can be added for use with the 
present invention as new network types and/or topologies are developed. In 
addition, it is to be appreciated that if multiple networks have the same 
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or similar characteristics, they could be handled by a single or common 
gateway service. 

The notification server 1000 preferably includes a central processing 
unit (not shown) which, in conjunction with other related functional 
subsystems (e.g., memory, control unit, etc.), as appreciated by those 
skilled in the art, is capable of running an applications program for 
controlling the one or more aspects of the notification server. For 
example, the central processing unit may be used for controlling access to 
any of the database information described above, transforming message data 
(e.g., transcoding),, communicating with services associated with the 
notification server (e.g., directory server 1050, awareness sever 1060, 
etc.), interfacing with users, or transmitting messages to the gateways 
1070, 1080, 1090. 

Figure 2 illustrates the architectural components comprising a 
gateway service such as 1070, 1080 and 1090, in accordance with one 
embodiment of the present invention. As shown in Figure 2, the gateway 
service 1070 preferably includes one or more queues 2000 of outstanding 
message delivery requests. Using these queues 2000, the present invention 
is able to support devices that disconnect and later reconnect to the 
notification network. In accordance with a preferred embodiment of the 
present invention, messages to be delivered simply wait in the queue 2000 
until such time as the recipient device reconnects. 

Those skilled in the art will recognise the potential problems 
associated with having a device disconnected sufficiently long so as to 
fill the available queue size with messages waiting to be delivered. 
Conventional means may be employed to solve these problems and may include, 
for example, the use of circular buffers, dropping new messages, dropping 
the oldest message, and so on, as appreciated by those skilled in the art. 
Service providers may offer different levels of service for different queue 
sizes, as well as for unlimited buffering of messages. Buffer size can 
also be limited, for example, by defining a maximum wait time per message. 
When a message is dropped because of an inability to successfully deliver 
the message to an intended recipient device, a purged message notification 
is preferably returned to the notification service for forwarding to the 
sender. 

With continued reference to Figure 2, a preferred embodiment of the 
present invention includes a transcoding engine 2010 for providing 
device-specific transcoding. Such transcoding may require detailed 
information regarding the characteristics of a particular device. The 
transcoding engine 2010 also preferably supports variations between 



different models of the same device. Unlike the transcoding engine 1040 
included in a preferred embodiment of the notification server 1000 shown in 
Figure 1, the transcoding engine 2010 included in the gateway service 1070 
of Figure 2 preferably possesses detailed knowledge about the device type 
serviced by a specific gateway, including the characteristics of each 
different model of a family of devices (e.g., the Palm I, II, m, v, VII 
devices of the PalmPilot" family of connected organizers) . This type of 
gateway is a device-specific proxy. An important advantage of this unique 
approach is the increased scalability that is possible when the majority of 
transcoding is performed by the gateway rather than by the notification 
server itself. In addition, the system of the present invention preferably 
supports adding new devices, with minimal reconfiguration or impact on the 
notification server design, since the detailed device information need not 
be added to the complex body of code included in the notification server. 

Figures 3A and 3B illustrate a logical flow diagram of the processing 
that occurs, in accordance with a preferred embodiment of the present 
invention, once the notification server 1000 (see Figure 1) receives a 
message to be delivered. With reference to Figure 3A, upon receipt of a 
message 3000, the notification server preferably first identifies the 
intended recipient of the message 3010 and verifies that the intended 
recipient is a subscriber (i.e., user) of the service 3020. if the 
intended recipient is not a subscriber of this service, the notification 
service preferably determines whether an error message should be generated 
3110. If not, processing stops 3100 at this point and the message is 
preferably dropped. If the present invention determines that an error 
message is to be returned to the sender, the error message is generated and 
subsequently returned 3120 to the sender before processing stops 3100. 

If the intended recipient is a subscriber of the notification 
service, the service preferably looks up the intended recipient's 
preferences 3030, which are preferably stored in the user preferences 
database 1020 (see Figure 1) described herein above. Depending on the 
content of those preferences, the notification system of the present 
invention preferably determines whether to continue processing 3040. Based 
upon the intended recipient's preferences, if it is determined 304 0 that 
processing should not continue, a response will preferably be generated 
3130 and processing subsequently stops 3100 (e.g., the intended recipient 
has indicated that it does not wish to receive messages from this sender) . 

With reference now to Figure 3B, assuming that processing is to 
continue, the notification service then preferably identifies 3050 the 
device (s) associated with the intended recipient, as well as the 
characteristics of those devices using the directory server 1050 (see 
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Figure 1) . It is to be appreciated that a device capable of exploiting 
resources in its environment (e.g., a handheld device near a large screen, 
publicly addressable display) may update the contents of the directory 
server 1050 so that the notification service can react appropriately to 
such dynamic changes in configuration. The notification service then 
preferably determines 3060 the accessibility of the intended recipient's or 
user's device (s). For example, the notification service system of the 
present invention may use an awareness service 1060 (see Figure 1) . 
Alternatively, the present system could identify the gateways associated 
with each device and query each gateway regarding the availability of the 
particular device (s) with the network. Such a query would likely be 
redirected to the switch associated with this device, although the present 
invention contemplates other means, as appreciated by those skilled in the 
art. 

With continued reference to Figure 3B, based upon the availability of 
the intended recipient's device (s) , the preferences of the recipient, the 
content of the message and the capabilities of each device, the 
notification server then preferably selects 3070 one or more devices to 
which to transmit the message. For each such device, the notification 
server preferably transforms the message 3080 (e.g., by transcoding), if 
necessary, and subsequently transmits the message 3090, either in its 
original form or a transformed version of the message, to the gateway 
associated with the selected device. For example, a message might be 
transformed by the notification service to remove elements of the message 
for which the gateway (or its associated device) is not capable of 
processing, or to filter confidential material prior to sending the message 
to an untrusted or unsecured gateway (e.g., removing confidential 
attachments or sending just a brief summary of information about the 
message, such as the subject line and the name of the sender) . As 
appreciated by those skilled in the art, the message may also be 
transmitted in an encrypted form, in accordance with conventional or 
proprietary encryption means, to provide an added level of security. After 
transmitting the message 3090, processing may then be completed 3100. 

The notification server may submit delivery requests to each gateway 
for which the recipient carries a device. To avoid multiple deliveries, 
the notification server could additionally maintain a queue of outstanding 
notifications and request that each gateway inform it when a successful 
delivery of the message has been completed. The notification server could 
then dequeue the now-redundant remaining delivery requests. In this 
manner, the notification system of the present invention can reduce the 
annoyance and cost to the user of having received multiple copies of the 
same message while minimising the delivery time of the message. Queuing 
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the message might, of course, incur a small cost, although the advantages 
to the recipient of not having to sort through multiple copies of the same 
messages would most likely outweigh any slight cost penalty. 

It is to be appreciated that the notification service 1000 (see 
Figure 1) could query the gateways for the cost of delivery and then make a 
determination as to whether to deliver the message based upon the lowest 
cost. It is to be appreciated that this decision may be based upon other 
metrics or attributes as well, such as, for example, the estimated time to 
deliver the message, etc. This query may result in a subsequent query from 
the gateways 1070, 1080, or 1090 to their associated switches. 
Furthermore, the gateways themselves, 1070, 1080, or 1090, may 
independently optimise the delivery of a message by querying their 
associated switches in a manner similar to that previously described 
herein. Querying the network for delivery attributes is especially useful 
when there are multiple gateways or multiple switches connected to a single 
gateway that could deliver the message Lo a particular user on a particular 
device, or when the user has multiple active devices at his or her 
disposal. It is to be appreciated that querying the gateways and/or 
switches may be unnecessary if the metric information is available through 
some other means. 

The notification server can also preferably initiate a query to 
determine the estimated time of arrival of messages sent to various 
devices. These queries may be made of the gateway and/or switch, or they 
may be made to an awareness service. With this information, the 
notification service can provide additional information to the sender of 
the message about how best to direct the message. Moreover, the 
notification server may automatically use such information itself in making 
delivery decisions that meet predetermined requirements (e.g., delivery 
time, cost, etc.) while minimising use of expensive devices and/or 
networks. 

If the sender of the message has requested a return receipt (e.g., 
similar to that offered by the U.S. mail system), then the notification 
server preferably records this information and passes this requirement to 
the gateway service. This information may be made in a simple hash table 
or any number of other data structures, as appreciated by those skilled in 
the art. 

Figure 4 is a logical flow diagram of the processing that occurs when 
the notification service sends a message to. a gateway, in accordance with a 
preferred embodiment of the present invention. This diagram illustrates 
the processing that preferably occurs in the gateway in response to the 
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transmission of message data 3090 (see Figure 3B) from the notification 
server. In the preferred embodiment of the present invention, the 
transmission of message data preferably triggers the gateway system to 
start 4000 processing that data by enqueuing the message 4010 for future 
delivery (i.e., storing the message in the message queue). The gateway 
system then preferably determines 4 020 whether the message requires a 
return receipt. If the present notification system determines that a 
return receipt is requested, the gateway records 4 030 that the message 
requires a return receipt, along with any additional information required 
to enable the gateway to send the return receipt back to the notification 
service at the appropriate time. Upon completion of this step, processing 
preferably stops 4040. As is evident in the diagram of Figure 4, the 
preferred embodiment includes little processing at this point, although it 
is to be appreciated that other, more complex, processing is contemplated 
(e.g., a delivery attempt could be made upon the initial receipt of the 
message), as known by those skilled in the art. Those skilled in the art 
will also recognise that the gateway service could send the return receipt 
directly, thus reducing the processing burden placed on the notification 
service . 

Figures 5A and 5B illustrate a logical flow diagram, in accordance 
with a preferred embodiment of the present invention, of the processing 
that occurs when the gateway processes the messages in its delivery queue 
(these messages arrived in the delivery queue as a result of the processing 
previously described in Figure 4). With reference to Figure 5A, for each 
pending message in the delivery queue, processing preferably starts 5000 by 
confirming 5005 whether the message has already been successfully 
delivered. If so, then essentially the only processing necessary for this 
request is that of sending the return receipt confirmation 5070 (see Figure 
5B) . If the notification service determines 5005 that the message has not 
yet been successfully delivered, then the system preferably checks to 
determine if the intended device to which the message is to be delivered is 
available in the network 5010. This determination 5010 may be made, for 
example, through the use of an awareness service 1060 (see Figure 1) or by 
querying the network's switch (e.g., 1100, 1110, 1120, or 1130). The 
gateway may also request a callback from either the awareness service or 
the switch if the status of the device changes. 

If the intended target device is not currently available, then the 
system preferably determines 5110 whether the message delivery should be 
attempted anyway, or whether the message delivery should be retried at a 
later time. If the notification system determines that the message 
delivery should be retried at a later time, then the system preferably 
stops 5100 processing this message and continues with the next message in 
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the queue. If a delivery attempt should be made, then processing simply 
continues as if the device were available. 

With continued reference to Figure 5A, if it is determined that the 
device is currently available, or if a delivery attempt is being made even 
though the intended device is not known to be available, then processing 
preferably continues by transforming 5020 the message for receipt by the 
intended device, assuming such transformation is required or desired. Such 
transformation may include those that require detailed knowledge of the 
intended device's characteristics (e.g., formatting for the device's 
screen, etc.). Once transformed, the gateway then preferably transmits 
5030 the message to the device, either directly or via a switch (or similar 
means) . The system then preferably determines whether or not the 
transmission was successful 5040. If the transmission fails, then 
processing preferably stops 5100. Otherwise, processing continues. 

With reference now to Figure 5B, if the transmission succeeds, then 
the message is preferably marked as having been delivered 5050. The 
present system then preferably determines 5060 whether or not a return 
receipt had been requested. If a return receipt had been requested, the 
notification server would be informed 5070 that the message had been 
successfully transmitted to the intended recipient device. When the target 
device includes the capability for bi-directional communication (e.g., a 
two-way pager, a Palm Pilot VII™, etc.), confirmation of receipt may be 
indicated by. the device. This second receipt (similar to a return receipt 
for U.S. Mail) is preferably sent to the sender of the message and gives 
two levels of delivery confirmation: one that it was sent (5070) and 
another that it was received. It is important to realise that this 
confirmation, however, only indicates that the user's device has received 
the message, not that the message has been received by the intended user of 
the recipient device. 

After delivery confirmation has been sent 5070, the present system 
preferably determines 5080 if the delivery confirmation notice was 
successfully received by the notification server. If the return receipt 
notification to the notification server 1000 fails, then processing of this 
message preferably stops 5100 (future processing of this message may 
continue with a retry of the return receipt notification and would not 
reprocess the message) . If the return receipt notification to the 
notification server 1000 succeeds, or if no return receipt was originally 
requested (as determined in step 5060), then the message is preferably 
dequeued 5090 and processing of this message subsequently completes 5100. 
It is to be appreciated that a sender may optionally request a response 
from the recipient. This response can be handled similarly to the way the 
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confirmation receipts have been described and may indicate that the 
intended recipient successfully received the message. 

Those skilled in the art will recognise that confirmation of message 
delivery 5070 may take place at many different levels. A direct response 
from the receiver is preferred, although the present invention contemplates 
other suitable alternatives, for example, an acknowledgement that the 
receiver received the message. Failing a direct response from the 
user/receiver (e.g., either because the receiver is using a device 
incapable of two-way messaging or because the receiver is avoiding the 
message), the sender might like as much information as possible. In a 
preferred embodiment of the present invention, the sender is notified that 
the message has been presented to the receiver by an application (such as, 
for example, displaying the message on a screen or playing an audio 
representation of the message on a speaker) . Those skilled in the art will 
further recognise that such a confirmation does not imply that the receiver 
has processed the message (i.e., that the receiver read the displayed 
message or listened to the audio message) . 

The system of the present invention may also preferably inform the 
sender that, for example, the message was successfully delivered to the 
device (but perhaps not yet displayed) , successfully transmitted through 
the network by the switch or similar manner (but receipt on the device is 
unknown), successfully transferred to the switch, or successfully 
transferred to the gateway, depending upon how much information is 
available to the system and how much reverse communication is possible. 

A system for providing a scalable pervasive notification service, in 
accordance with the present invention, preferably includes a notification 
server operatively connected to one or more gateways. Each gateway, in 
turn, is connected, either directly or indirectly, to one or more recipient 
devices associated with a user(s) of the notification service. The gateway 
includes a message queue, for storing messages to be delivered, and/or a 
transcoder for transforming the format type of a message, received from the 
notification server, to a different format type adapted for use by the 
intended recipient devices. 

Although illustrative embodiments of the present invention have been 
described herein with reference to the accompanying drawings, it is to be 
understood that the invention is not limited to those precise embodiments, 
and that various other changes and modifications may be affected therein by 
one skilled in the art without departing from the scope of the invention. 
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CLAIMS 

1. A notification service for communicating messages to one or more 
intended recipient devices associated with at least one user of said 
notification service, . said notification service comprising: 

a notification server, the notification server including one or more 
databases for storing at least one of administrative information, user 
preferences, gateway information, directory service information and 
awareness information; and 

at least one gateway operativeiy connected to the notification 
server, the at least one gateway including at least one of: 

a message queue for storing messages to be delivered to 
said one or more recipient devices operativeiy connected to the at 
least one gateway; and 

a transcoder for transforming a message, received from 
said notification server, from a first format type to a second format 
type for use by said one or more intended recipient devices 
operativeiy connected to the gateway. 

2. A notification service according to Claim 1, further comprising: 

a user interface operativeiy connected to said notification server, 
the user interface enabling modification of said information stored in said 
one or more databases. 

3. A notification service according to Claim 1 or 2, wherein said 
notification server further comprises a transcoder for transforming a 
message to be delivered from a first format type to a second format type. 

4 . In a notification service comprising a notification server 
operativeiy communicating with at least one gateway, a method for 
communicating a message to one or more recipient devices associated with at 
least one user of said notification service, said one or more devices being 
operativeiy connected to said at least one gateway, said method, performed 
by said notification server, comprising the steps of: 

identifying, upon receiving a message from a sender, an intended 
recipient of said message and determining whether said intended recipient 
is a user of the notification service; 
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retrieving, if said intended recipient is a user of said notification 
service, from a storage medium operatively coupled to the notification 
server, at least one of: 

information relating to said intended recipient; and 

information relating to said one or more devices 
associated with said intended recipient; 

determining, on the basis of said information retrieved from said 
storage medium, whether said message is to be delivered; 

identifying one or more devices, and characteristics corresponding 
thereto, associated with said intended recipient; 

determining the availability of said one or more devices, associated 
with said intended recipient, for receiving said message; and 

transmitting said message to one or more gateways associated with at 
least one available device from said one or more devices associated with 
said intended recipient. 

5. A method according to Claim 4, further comprising the step of: 

returning an error indication to the sender of said message if said 
intended recipient is not a user of the notification service. 

6. A method according to Claim 4 or 5, further comprising the step of: 

determining if the sender of said message has requested a return 
receipt, said return receipt indicating that said message has been 
delivered to said at least one available device; and 

transmitting information relating to whether said return receipt has 
been requested by the sender to said one or more gateways associated with 
said at least one available device. 

7. A method according to any of Claims 4 to 6, further comprising the 
step of: 

transforming, for each device of said at least one available device, 
said message from a first format type to a second format type adapted for 
use by said available device, said transforming step being performed prior 
to said transmitting step. 
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8. A method according to any of Claims 4 to 7, further comprising the 
steps of: 

generating a response, based on said information retrieved from said 
storage medium, said response indicating that said message is undeliverable 
to said intended recipient; and 



transmitting said response to the sender. 

10 9. In a notification service comprising a notification server 

operatively communicating with at least one gateway, said at least one 
gateway including a message queue for storing one or more messages, a 
method for communicating a message to one or more recipient devices 
associated with at least one user of said notification service, said one or 

15 more devices being operatively connected to said at least one gateway, said 

method, performed by said at least one gateway, comprising the steps of: 



receiving a message from said notification server; 

20 storing said message in said message queue; 

retrieving a message to be delivered from said message queue; 

determining whether said message retrieved from said message queue 
25 has already been delivered to said one or more recipient devices; 



transmitting said message retrieved from said message queue to said 
one or more recipient devices if said message has not already been 
delivered; 

30 

determining whether said transmitting of said message was successful; 

and 



removing said message from said message queue if said transmitting 
35 step was successful. 



10. A method according to Claim 9, further comprising the steps of: 

determining whether said message received from the notification 
4 0 server requires a return receipt; 

storing a return receipt request if said notification server requires 
said return receipt; and 
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transmitting, if said return receipt is requested, a delivery 
confirmation to at least one of said notification server and a sender of 
the message, said delivery confirmation indicating that said message was 
successfully transmitted to said one or more recipient devices. 

11. A method according to Claim 9 or 10, further comprising the steps of: 

determining whether an intended device to which said message is to be 
delivered is available for receiving messages; and 

determining, if said intended device is not available, whether to 
proceed with message delivery. 

12. A method to any of Claims 9 to 11, wherein said at least one gateway 
further includes a transcoder, said method further comprising the step of: 

transforming, for each device of said one or more recipient devices, 
said message from a first format type received from said notification 
server to a second format type adapted for use by said recipient device, 
said transforming step being performed prior to said transmitting step. 

13. In a notification service comprising a notification server 
operatively communicating with at least one gateway, said at least one 
gateway including a transcoder, a method for communicating a message to one 
or more recipient devices associated with at least one user of said 
notification service, said one or more devices being operatively connected 
to said at least one gateway, said method, performed by said at least one 
gateway, comprising the steps of: 

receiving a message from said notification server; 

transforming,, for each device of said one or more recipient devices, 
said message from a first format type received from said notification 
server to a second format type adapted for use by said recipient device; 
and 

transmitting said message retrieved from said message queue to said 
one or more recipient devices if said message has not already been 
delivered. 

14. A method according to Claim 13, further comprising the steps of: 

determining whether said message received from the notification 
server requires a return receipt; 
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storing a return receipt request if said notification server requires 
said return receipt; and 

transmitting, if said return receipt is requested, a delivery 
5 confirmation to said notification server, said delivery confirmation 

indicating that said message was successfully transmitted to said one or 
more recipient devices . 

15. A method to Claim 13 or 14, further comprising the steps of: 

10 

determining whether an intended device to which said message is to be 
delivered is available for receiving messages; and 

determining, if said intended device is not available, whether to 
15 proceed with message delivery. 

16. A notification service substantially as hereinbefore described with 
reference to the accompanying drawings. 
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17. In a notification service, a method of communicating messages to one 
or more recipient devices substantially as hereinbefore described with 
reference to the accompanying drawings. 
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